NOTE: PR best viewed with whitespace changes disabled

Network requests before this PR

Note the api call is blocking the loading of the views.

Network requests after this PR

The api call and the views calls are done in parallel

(NOTE: The api call is starting a bit late due to Chrome's concurrent request limit (6). It will start even earlier on a prod deployment under either HTTP/2, or if the Admin UI is served from a different domain to the API)

More to come

You'll notice this PR only addresses the Content field's blocks and nothing else. I purposely wanted to keep this PR small to guage reception. If it all looks 👍, then I can use the same technique with all the other field types, and for Cell / Filters too.

Motivations

There are two main motivations for this change:

1. Performance as noted above
2. The Content Editor needs to be able to deserialise the Slate.js JSON blob returned by the API request. Until it's deserialised, it can't be rendered. But the way the code is structured before this PR; we don't load the views until we have the complete (deserialised) data. 🐓&🥚. This change makes it possible to ensure the deserialisation logic (which the views provide) is preloaded before trying to move on with deserialsation & display.

Inspiration

This solution was partly inspired by Facebook's recent F8 video on how they make their dynamic view loading as performant as possible: https://developers.facebook.com/videos/2019/building-the-new-facebookcom-with-react-graphql-and-relay/